Ambient IoT Rel-19

 RAN1#116

9.4      Study on solutions for Ambient IoT (Internet of Things) in NR

Please refer to RP-234058 for detailed scope of the SI.

R1-2401767         Session notes for 9.4 (Study on solutions for Ambient IoT in NR)       Ad-Hoc Chair (Huawei)

Friday decision: The session notes are endorsed and contents reflected below.

[116-R19-A_IoT] – Matthew (Huawei)

Email discussion on Rel-19 Ambient IoT

-        To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

R1-2400328         Ambient IoT Study Item work plan           CMCC, Huawei, T-Mobile USA

R1-2401404         Skeleton for TR 38.769 "Study on Solutions for Ambient IoT (Internet of Things)" v0.0.1           Huawei

Friday session

R1-2401797         Editor’s summary for discussion on TR 38.769 skeleton              Huawei

R1-2401795         Skeleton for TR 38.769 "Study on Solutions for Ambient IoT (Internet of Things)" v0.0.1           Huawei

Decision: The skeleton for TR 38.769 in R1-2401795 is endorsed.

R1-2400783         Operator view on Ambient IoT design targets             T-Mobile USA Inc.

R1-2400956         LS to SA3 requesting Ambient IoT security requirements        T-Mobile USA Inc.

9.4.1       Evaluation on Ambient IoT in NR

9.4.1.1       Evaluation assumptions and results

Including assumptions on coverage and coexistence evaluations, link budget calculations, and remaining design targets of TR 38.848

R1-2400075         Evaluation assumptions and results for Ambient IoT              Ericsson

·       Regarding the coverage targets, the following aspects should be considered:

o   Different coverage targets can be considered for different A-IoT device types (A+/B/C) within interval distance of 10 – 50 m. The specific targets can be defined after RAN1 has carried out the link-budget exercises.

o   For the passive devices (A+/B), RAN 1 should agree on assumptions regarding the distances between the CWT and A-IoT devices since this directly impacts coverage assessments for the uplink.

o   RAN1 can refine the target based on band assumptions, relevant channel model(s), ISD(s), etc., as needed.

·       Considering that the inventory request time should also be assumed in assessing the latency, the latency definition can be refined as follow:

o   For rUC1, indoor inventory: The time interval between the time that the inventory request is sent from BS/intermediate UE and the time that the inventory report is successfully received at BS/intermediate UE [e.g., with 99% probability].

o   For rUC2, indoor command: The time interval between the time that the DL command is sent from BS/intermediate UE and the time that the data is successfully received at A-IoT device [e.g., with 99% probability].

·       Discuss whether it is motivated to also introduce a latency target for the total time required for successful inventory of multiple devices in the cell [e.g., with 99% probability].

·       For topology 1, use the BS and A-IoTs distributions in Table 1 as the initial reference for system-level simulations, capacity, and coexistence evaluations.

o   FFS on the other possible distributions for A-IoT devices.

·       2D distributions of topology 2 is for further study.

·       The distribution of CWTs is considered for further study.

·       Down-select between the following coverage evaluation methodology alternatives:

o   Alt 1. Adopt the link budget templates described in TR 38.875 or TR 38.830 as the starting point.

o   Alt 2: Use the simple coverage evaluation methodology primarily based on path loss.

·       Consider the following path-loss models:

o   Topology 1:

§  DL and UL (links between A-IoT and BS): InF-DH NLOS,

§  CWT to A IoT device link, for passive devices: InF-DH LOS.

o   Topology 2:

§  DL and UL (links between A-IoT and intermediate node): InF-DL,

§  NLOS, for passive devices CWT to A IoT device: InF-DL LOS.

·       The assumptions listed in Table 2 are included as coverage evaluation assumptions.

·       If coverage evaluation methodology alternative 1 is selected, MPL is used as the coverage metric and use the same methodology as 38.830 section 4.2, to convert target distances to the target MPLs.

·       If coverage evaluation methodology alternative 1 is selected, use the link budget template, Table A.3, in 38.830 (or the template in 38.875 (for RedCap UEs)) as the starting point and adapt it accordingly for A-IoT devices coverage evaluation.

·       If coverage evaluation methodology alternative 1 is selected, the assumptions listed in Table 3 are included as link level simulation assumptions.

·       If coverage evaluation methodology alternative 2 is adopted, the maximum distance as the coverage metric can be obtained as the maximum distance for which the received power is larger than the receiver sensitivity.

·       If coverage evaluation methodology alternative 2 is adopted, the assumptions listed in Table 4 are included for coverage evaluation.

·       If RAN1 reaches consensus, send an LS to RAN4 with basic evaluation assumptions.

·       RAN1 needs to come to an agreement on the following assumptions regarding coexistence:

o   parameters related to CWT, including,

§  CWT transmission power, topology, and deployment

§  whether to consider both mono-static and bi-static configurations,

§  what band (UL or DL) to use for CW transmission

o   proportion of the A-IoT device types within a cell/carrier/band

o   aspects related to deployment mode: in-band, standalone. and guard band deployment modes.

·       For topology 1, consider the CWT node deployment to be uniform but with limited transmission power and range.

Decision: The document is noted.

R1-2401306         On evaluation assumptions and results for A-IoT   MediaTek Inc.

·       For the link-level simulation of A-IoT system, a bandwidth of 180kHz under 15kHz numerology at 900MHz FDD spectrum could be considered as a starting point.

o   FFS larger bandwidth, e.g., X MHz

·       For the link-level simulation of A-IoT system, both OOK-1 and OOK-4 could be considered.

o   FFS the value of M for OOK-4

·       For the link-level simulation of A-IoT system, consider Manchester channel coding as a baseline for both A-IoT DL and UL, and FFS others.

·       Evaluate synchronization performance related to preamble design

·       Evaluate detection and demodulation performance related to waveform, payload, CRC, and optional FEC design

·       Evaluate RF envelop detector by BB equivalent simulation using a wide LPF. Specifically, consider a 1-order LPF with a cut-off frequency at 5MHz.

·       Evaluate homodyne receiver by BB equivalent simulation using a narrow LPF. Specifically, consider a 3-order LPF with a cut-off frequency at 180kHz.

·       For RF envelope detector, consider the initial sampling frequency offset (SFO) of 103ppm, 104ppm, 105ppm

·       For homodyne architecture with envelop detector, consider the max sampling carrier frequency offset (CFO) and sampling frequency offset (SFO) of 10ppm and 100ppm

·       Evaluate CDF of timing error after synchronization for given preamble design

·       Evaluate detection performance regarding residue timing error after synchronization over preamble

·       Evaluate detection performance assuming 5-order Butter with 180K cut off at tag reader in UL reception

·       Consider using at least 1, 2, or 4 antennas for the tag reader in uplink reception.

·       Evaluate UL performance regarding fading channel effects before tone rejection

·       Consider the following channel assumption: A LOS channel model (TDL-A), additive white Gaussian noise (AWGN)

·       Additionally Evaluate detection performance assuming ASCS of 0dB or ACS of 31.5dB

·       In scenarios with full-duplex interference, assume that CW interference is at least 40dB stronger than the uplink (UL) when the CW emitter is inside the UL path, and 20dB stronger when the emitter is outside the UL path.

·       The link budget analysis for A-IoT should study both carrier wave provided inside and outside the connectivity topology.

·       The link budget analysis for A-IoT should include at least CW link, A-IoT DL and A-IoT UL.

·       The link budget analysis for A-IoT should have a common value (range) for at least the following parameters: reader Tx power, emitter Tx power (if any), reader sensitivity, tag activation threshold, tag sensitivity, tag backscattering loss, tag reflection amplifier factor, tag Tx power (only for active tag), tag amplifier factor (only for active tag).

·       The link budget analysis for A-IoT should use 3GPP InF pathloss model.

·       The link budget of Topology 2 can be inferred on top of Topology 1

·       Study whether/how the energy storage affects the link budget analysis of device type I and II

Decision: The document is noted.

R1-2400056              Discussion on evaluation assumptions and results for Ambient IoT              Spreadtrum Communications

R1-2400087         Discussion on evaluation assumptions and results for Ambient IoT devices          FUTUREWEI

R1-2400113         Evaluation assumptions for Ambient IoT       Huawei, HiSilicon

R1-2400244         Evaluation methodologies assumptions and results for Ambient IoT         vivo

R1-2400329         Discussion on evaluation methodology and assumptions              CMCC

R1-2400361         Initial views on Evaluation assumptions and results for Ambient IoT         Nokia, Nokia Shanghai Bell

R1-2400435         The evaluation methodology and preliminary results of Ambient IoT         CATT

R1-2400486         Discussion on Ambient IoT evaluations        ZTE, Sanechips

R1-2400560         Evaluation methodology and assumptions for Ambient IoT              xiaomi

R1-2400609         Discussion on evaluation assumptions and results for A-IoT              OPPO

R1-2400662         Discussion on evaluation assumptions and results for Ambient IoT         China Telecom

R1-2400734         Considerations for evaluation assumptions and results              Samsung

R1-2400805         Discussion on ambient IoT evaluation framework       NEC

R1-2400855         Evaluation assumptions for Ambient IoT       Sony

R1-2400885         Discussion on the evaluation assumptions for Ambient IoT devices  Lenovo

R1-2400924         The Evaluation on Ambient IoT in NR          Comba

R1-2400942         Considerations for evaluation assumptions and results              Semtech Neuchatel SA

R1-2401014         Views on evaluation assumptions and link budget analysis for AIoT      Apple

R1-2401156         Discussion on Evaluation Assumptions and Results for Ambient IoT         Indian Institute of Tech (M), IIT Kanpur

R1-2401180         Evaluation assumptions for Ambient IoT       InterDigital, Inc.

R1-2401326         Discussion on Ambient IoT evaluation          LG Electronics

R1-2401443         Evaluation Assumptions and Results             Qualcomm Incorporated

R1-2401647         FL summary #1 for Ambient IoT evaluation           Moderator (CMCC)

From Tuesday session

Agreement

For this study item, the coverage evaluation methodology is based on the following steps.

For an evaluation scenario

• For each of the link i,
• Step 1: Obtain the required SINR for the physical channels under target scenarios and service/reliability requirements if Budget-Alt2 is used for this link i.
• Step 2: Obtain the receiver sensitivity using the method Budget-Alt1 (if a predefined threshold is assumed to derive the receiver sensitivity) or Budget-Alt2 (if no predefined threshold is assumed to derive the receiver sensitivity).
• Step 3: Obtain the coverage performance for link i based on the receiver sensitivity from step 2 and link budget template.
• The coverage results for each link are provided.
• FFS: what links are evaluated besides R2D and D2R (e.g., RF-EH)
• FFS whether/how to model the interference
• FFS: for which device(s) a predefined threshold is assumed

Note the following alternatives for obtaining receiver sensitivity are defined,

• Budget-Alt1: receiver sensitivity is derived by a predefined threshold and no LLS is needed for link budget calculation
• The results rely on the received sensitivity and maximum transmit power, and directly calculate the maximum distance / pathloss based on these values and other related parameters. The link-level simulation (LLS) performances, such as required SINR can be satisfied for such case and no LLS is needed for link budget calculation.
• Budget-Alt2: receiver sensitivity is derived by required SINR which is given by LLS results
• The results rely on link-level simulation results, e.g., required SINR which corresponds to detail LLS assumptions (e.g., BW, coding, data rate). And based on the required SINR, the received sensitivity can be calculated and then the maximum distance / pathloss can be derived.
• Note: For noise power, a noise figure value needs to be provided.

Agreement

MPL and distance is used as performance evaluation metric for link budget calculation.

·       Note: the distance is derived from MPL and corresponding pathloss model.

·       FFS: Pathloss model

Agreement

The following pathloss model is used in the coverage evaluation.

• For D1T1,
• InF-DH defined in TR38.901 is used.
• Decide which of the following is used for each link,
• NLOS
• LOS
• FFS: InF-SH
• For D2T2, down-select from the following path loss models
• InF-DL defined in TR38.901 where the BS path loss model is reused for intermediate-UE with antenna height of 1.5m
• InH-Office model defined in TR38.901, (a.k.a, InH_B in Report ITU-R M.2412-0) where the BS path loss model is reused for intermediate-UE with antenna height of 1.5m
• Decide which of the following is used for each link,
• NLOS
• LOS

R1-2401735         FL summary #2 for Ambient IoT evaluation           Moderator (CMCC)

From Thursday session

Conclusion

Companies are encouraged to consider Table 3.4.2 in R1-2401735 for their contributions to RAN1#116bis regarding link budget template.

Final summary in R1-2401874.

9.4.1.2       Ambient IoT device architectures

R1-2400735         Considerations for Ambient-IoT device architectures              Samsung

·       Prioritize provisioning CW signal directly at the backscattering frequency, which eliminates the need for a frequency shifter. Further study regulations and coexistence/compatibility issues.   

·       Considering the low-complexity requirements of A-IoT devices, prioritize a simplest modulation scheme for backscattering transmission, e.g., OOK.

·       Strive for harmonized and unified system designs for Type-1 and Type-2 backscatter devices, without requiring a FDD frequency shifter. 

·       Prioritize a receiver architecture based on RF envelop detector over IF or BB envelop detector. Prioritize a transmitter architecture based on backscattering over active transmission. 

Decision: The document is noted.

R1-2401015         Views on device architecture for AIoT       Apple

·       For low-complexity backscattering device, following architecture could be considered as a baseline assumption for this study:

·       For the purpose of our evaluations, we can at least consider activation threshold values of { -20dBm, -25dBm}

·       For the lower- category device (_~1µW of peak power consumption), OOK-based receiver with simple RF envelope detection can be considered as the baseline at least for evaluation purpose

·       For the higher- category device few hundreds of µW of peak power consumption), more complex receiver architecture like heterodyne receivers can be considered for evaluation purpose

o   However, for PHY design perspective, this should not impact the harmonized design target between lower-category and higher-category device

Decision: The document is noted.

R1-2400057         Discussion on Ambient IoT device architectures         Spreadtrum Communications

R1-2400076         Ambient IoT device architectures   Ericsson

R1-2400088         Discussion on Ambient IoT device architectures              FUTUREWEI

R1-2400114         Ultra low power device architecture for Ambient IoT Huawei, HiSilicon

R1-2400187         Discussion on ambient IoT architecture        TCL

R1-2400245         Discussion on Ambient IoT Device architectures        vivo

R1-2400330         Discussion on Ambient IoT device architectures         CMCC

R1-2400362         Initial views on Ambient IoT device architectures      Nokia, Nokia Shanghai Bell

R1-2400436         Study of the Ambient IoT devices architecture            CATT

R1-2400487         Discussion on Ambient IoT device architectures         ZTE, Sanechips

R1-2400524         Discussion on Ambient IoT device architectures         Honor

R1-2400561         Discussion on ambient IoT device architectures          xiaomi

R1-2400610         Discussion on device architecture for A-IoT device    OPPO

R1-2400856         Ambient IoT device architectures   Sony

R1-2400887         Discussion on the Ambient IoT device architectures   Lenovo

R1-2400926         Ambient IoT device architectures   Comba

R1-2401065         Ambient IoT device architectures   China Unicom

R1-2401182         Device architectures for Ambient IoT            InterDigital, Inc.

R1-2401264         Discussion on Ambient IoT device architectures         IIT Kanpur, Indian Institute of Tech (M)

R1-2401275         Discussion on Ambient IoT device architectures         CEWiT

R1-2401307         On Ambient IoT device architectures            MediaTek Inc.

R1-2401327         Discussion on Ambient IoT device architectures         LG Electronics

R1-2401444         Ambient IoT Device Architecture   Qualcomm Incorporated

R1-2401682         FL Summary#1 for 9.4.1.2 Ambient IoT Device Architecture              Moderator (Qualcomm)

From Tuesday session

Agreement

For the purpose of the study, RAN1 uses the following terminologies:

·       Device 1: ~1 µW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10^X ppm, neither DL nor UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally.

·       Device 2a: ≤ a few hundred µW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10^X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is backscattered on a carrier wave provided externally.

·       Device 2b: ≤ a few hundred µW peak power consumption, has energy storage, initial sampling frequency offset (SFO) up to 10^X ppm, both DL and/or UL amplification in the device. The device’s UL transmission is generated internally by the device.

R1-2401703         FL Summary#2 for 9.4.1.2 Ambient IoT Device Architecture              Moderator (Qualcomm)

From Wednesday session

Agreement

Study at least the following blocks for device 1 architecture.

• Antenna could be either shared or separate for RF energy harvester and receiver/transmitter.
• Matching network is to match impedance between antenna and other components (including RF energy harvester and receiver related blocks).
• RF energy harvester can include rectifier performing RF signal (AC) to DC conversion.
• Energy storage (e.g., capacitor) stores harvested energy from RF energy harvester.
• Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.
• Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
• Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.
• Clock generator provides required clock signal(s).

• Reception related blocks
• RF BPF for improving selectivity.
• Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak power consumption target also need to be considered.
• RF Envelope Detector converts RF signal to baseband.
• BB LPF can filter out harmonics and high frequency components to improve input signal quality to comparator.
• Depending on implementation, it may not exist. Presence of BB LPF is assumed for the study.
• Comparator determines high/low of input signal.
• Transmission related blocks
• Backscatter modulator switches impedance to modulate backscattered signal with tx signal from BB logics. Waveform/Modulation type is FFS.

R1-2401704         FL Summary#3 for 9.4.1.2 Ambient IoT Device Architecture              Moderator (Qualcomm)

From Thursday session

Agreement

Study at least following blocks for device 2a architecture w/ RF-ED receiver.

• Antenna could be either shared or separate for RF energy harvester (if present) and receiver/transmitter.
• Matching network is to match impedance between antenna and other components (including RF energy harvester (if present) and receiver related blocks).
• Energy harvester.
• Energy storage (e.g., capacitor) stores harvested energy from energy harvester.
• Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.
• Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
• Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.
• Clock generator provides required clock signal(s).
• Reflection amplifier can amplify reflected backscattered signal.
• FFS study applicability of amplification of rx signal, power consumption.
• At least one of R2D/CW2D and D2R could be amplified by either reflection amplifier or LNA.
• Reception related blocks
• RF BPF filter for improving selectivity.
• Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak power consumption target also need to be considered.
• FFS: LNA for improving signal strength and sensitivity of receiver.
• At least one of R2D/CW2D and D2R could be amplified by either reflection amplifier or LNA.
• RF envelope detector (RF-ED) detects envelope from RF signal.
• BB amplifier amplifies BB signal to improve signal strength.

• BB LPF can filter out harmonics and high frequency components to improve input signal quality to comparator/ADC.
• Depending on implementation, it may not exist.

• Comparator or N-bit ADC
• Transmission related blocks

o   Backscatter modulator switches impedance to modulate backscattered signal with tx signal from BB logics.

o   FFS: Large Frequency shifter (e.g., tens of MHz) for shifting backscattered signal from one frequency (e.g., FDD-DL frequency) to another frequency (e.g., FDD-UL frequency).

Final summary in R1-2401835.

9.4.2       Physical layer design for Ambient IoT

9.4.2.1       General aspects of physical layer design

Including numerologies, bandwidths, multiple access, waveform, modulation, and coding

R1-2400331         Discussion on general aspects of Ambient IOT physical layer design   CMCC

·       Single numerology with 15KHz and normal CP is supported for A-IOT.

·       OOK modulation is used for A-IOT Reader-to-device link.

·       MC-ASK waveform OOK-1 and OOK-4 can be the starting point for A-IOT downlink waveform, whether OOK-1 or OOK-4 is used depending on the downlink data rate.

·       OOK modulation is considered as baseline for Ambient-IoT device-to-reader link.

·       PSK modulation can be further studied for Ambient-IoT device-to-reader uplink.

·       Line code can be adopted to assist bit synchronization

o   For downlink, support one or both of PIE and Manchester can be considered;

o   For uplink, Manchester, Miller code and FM0 can be further analyzed.

·       No FEC code is applied for A-IOT downlink.

·       Convolutional Code or Tail-biting Convolutional Code can be further studied for A-IOT uplink.

·       The following coding schemes are considered for Ambient IoT,

·       One RB or multiple RBs bandwidth can be studied for downlink transmission.

·       Scalable bandwidth that is multiple of 15KHz can be considered for uplink transmission.

·       For in-band deployment of A-IOT with NR, further study how to avoid interference from NR to A-IOT device reception.

·       For A-IOT, slotted-ALOHA is used as the basic multiple access scheme.

·       Further study uplink multiple access scheme within each inventory slot for both Contention resolution and Data transmission stage to improve the inventory efficiency by considering proper evaluation metrics.

Decision: The document is noted.

R1-2400777         Consideration on general aspects of physical layer Fujitsu

·       AIoT devices are:

o   Narrow band, equal to or lower than one RB in NR (with 15kHz SCS).

o   Single carrier wave rather than OFDM/SC-FDM.

o   TDMA, which should be the basic assumption on the multiple access manner. FDMA could be a supplement if the frequency spectrum is abundant.

o   At least without channel coding in downlink.

o   Perhaps, with channel coding in uplink if the channel coding algorithm is simple enough.

o   Scrambling can be supported in both downlink and uplink to protect data carried in downlink and uplink in a certain degree..

·       From the AIoT device aspect, the system could be asynchronous.

·       From the gNB aspect, the system should still be ‘synchronous’.

Decision: The document is noted.

R1-2400058         Discussion on general aspects of physical layer design for Ambient IoT   Spreadtrum Communications

R1-2400077         General aspects of physical layer design for Ambient IoT              Ericsson

R1-2400089         Discussion on physical layer design for Ambient IoT devices              FUTUREWEI

R1-2400115         On general aspects of physical layer design for Ambient IoT              Huawei, HiSilicon

R1-2400246         Discussion on General Aspects of Physical Layer Design              vivo

R1-2400363         Initial views on General aspects of physical layer design for Ambient IoT        Nokia, Nokia Shanghai Bell

R1-2400385         Optimal Training Sequence for Backscattering Tag    BJTU

R1-2400437         Discussion on general aspects of physical layer design              CATT

R1-2400459         Discussion on general aspects of ambient IoT physical layer design    NEC

R1-2401493         Discussion on general aspects of physical layer design for Ambient IoT        ZTE, Sanechips   (rev of R1-2400488)

R1-2400562         Discussion on physical layer design of Ambient IoT   xiaomi

R1-2400611         Discussion on general aspects of physical layer design of A-IoT communication   OPPO

R1-2400630         Discussion on general aspects of physical layer design              Sharp

R1-2400663         Discussion on general aspects of physical layer design for Ambient IoT        China Telecom

R1-2400736         Discussion on general aspects of Ambient IoT            Samsung

R1-2400756         On General Physical Layer Design Considerations for Ambient IoT Applications Lekha Wireless Solutions

R1-2400857         General aspects of physical layer design for Ambient IoT              Sony

R1-2400872         Discussions on general aspects for A-IoT      Intel Corporation

R1-2400888         Discussion on the Physical layer design for Ambient IoT devices              Lenovo

R1-2400934         Discussions on general aspects of physical layer design for Ambient IoT        Ruijie Network Co. Ltd

R1-2401016         Views on general physical layer design aspects for AIoT              Apple

R1-2401034         General aspects of physical layer design for Ambient IoT              Panasonic

R1-2401119         Study on general aspects of physical layer design for Ambient IoT              NTT DOCOMO, INC.

R1-2401160         Views on physical layer design       Comba

R1-2401183         Physical layer design for Ambient IoT           InterDigital, Inc.

R1-2401230         Discussion on general aspects of physical layer design for ambient IoT         ETRI

R1-2401258         Discussion on general aspects of physical layer design              Google

R1-2401265         Discussion on General aspects of physical layer design             IIT Kanpur, Indian Institute of Tech (M)

R1-2401276         Discussion on General aspects of physical layer design              CEWiT

R1-2401308         On general aspects of physical layer design for A-IoT MediaTek Inc.

R1-2401328         General aspects of Ambient IoT physical layer design LG Electronics

R1-2401350         General aspects of physical layer design       Nordic Semiconductor ASA

R1-2401445         General aspects of physical layer design       Qualcomm Incorporated

R1-2401464         General aspects of physical layer design for Ambient IoT              ITL

R1-2400755         Modulation Comparison for AIoT   Wiliot Ltd.           (Moved from 9.4)

R1-2401567         Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #1            Moderator (Huawei)

From Wednesday session

Agreement

A-IoT DL study includes an OFDM-based waveform from A-IoT R2D (reader-to-device) perspective.

• Depending on what modulation(s) are decided to be studied:
• Study whether/how to handle CP at transmitter/device/design
• Study other characteristics of the OFDM waveform, e.g.:
• CP-OFDM
• DFT-s-OFDM
• Etc.
• The type of OFDM waveform is transparent to A-IoT device.

Other waveforms from DL transmitter’s perspective can be proposed, and further discussion will consider whether or not they are included in the study.

Agreement

A-IoT DL study includes OOK from DL transmitter’s perspective.

• For an OFDM waveform, assume OOK-1 for single-chip per OFDM symbol transmission, and OOK-4 for M­-chip per OFDM symbol transmission, starting from definitions in TR 38.869.
• FFS value(s) of M.

• FFS: Any changes needed from the definitions in TR 38.869.
• FFS: Exact definition of chip
• If other DL waveforms are included, further elaboration of the transmitter’s OOK generation would be needed.

R1-2401568         Feature Lead Summary for 9.4.2.1: “Ambient IoT – General aspects of physical layer design” #2            Moderator (Huawei)

From Thursday session

Agreement

For R2D, line codes studied are: Manchester encoding and pulse-interval encoding (PIE).

• FFS: Mapping(s) from bit(s) to line-code codewords
• FFS: Time domain definition of e.g., chips and relation to OFDM symbols, resource allocation unit, etc.

Agreement

Regarding FEC, R2D with no forward error-correction code (FEC) is studied as baseline.

• Evaluations would be by comparison to this baseline

Agreement

R2D study assumes use of CRC. FFS which CRC generator polynomial(s) are assumed, and if any cases are included with no CRC.

• FFS: Association, if any, between down-selected CRC(s) and message size, considering at least false-alarm rate target

Agreement

D2R study assumes use of CRC. FFS which CRC generator polynomial(s) are assumed, and if any cases are included with no CRC.

• FFS: Association, if any, between down-selected CRC(s) and message size, considering at least false-alarm rate target

Agreement

At least the following bandwidths for R2D are defined for the purpose of the study:

• Transmission bandwidth, B_tx,R2D from a Reader perspective: The frequency resources used for transmitting R2D
• Occupied bandwidth, B_occ,R2D from a Reader perspective: The frequency resources used for transmitting R2D, and potential guard band
• B_occ,R2D ≥ B_tx,R2D
• FFS: Further constraint(s) e.g. B_occ,R2D = B_tx,R2D.
• Possible values of each bandwidth are FFS

Final summary in R1-2401851.

9.4.2.2       Frame structure and timing aspects

Including synchronization and timing, random access, scheduling and timing relationships

R1-2400116         On frame structure and timing aspects of Ambient IoT              Huawei, HiSilicon

·       Considering the large SFO of up to 10⁵ ppm for the extreme-low power Ambient IoT device, Ambient IoT is assumed to be an asynchronous system.

·       For the timing acquisition of each downlink transmission in Ambient IoT, downlink preamble is supported to indicate the starting time and the chip length used for the following PDSCH transmission.

·       For the chip-level timing tracking during each downlink transmission in Ambient IoT, the rising- or falling- edge in each codeword of line code is used to e.g. continuously refresh the timing reference point.

·       For the timing acquisition and tracking of uplink transmissions in Ambient IoT, uplink preamble, midamble, and postamble are supported.

·       Slot and frame are not used as time units for Ambient IoT.

·       For downlink transmissions, the basic time unit is defined as chip length.

·       The start and end of Ambient IoT downlink transmission is not restricted to be aligned with the boundary of NR slot.

·       For uplink transmission in Ambient IoT, the basic time unit is defined as chip length.

·       For uplink transmission in Ambient IoT, multiple chip lengths corresponding to the multiple uplink signal bandwidths are supported.

·       The study assumes no dedicated physical channel or signal for random access.

·       For downlink scheduling information in Ambient IoT, a PDCCH-like channel is not included in the study.

·       For uplink scheduling information in Ambient IoT, a PDCCH-like channel is not included in the study.

·       The following timing relationships are defined for an Ambient IoT system:

o   T_DL-UL: Between a downlink transmission and the corresponding uplink transmission immediately following it.

o   T_UL-DL: Between an uplink transmission and the corresponding downlink transmission immediately following it.

o   T_DL-DL: Between two consecutive downlink transmissions to the same device.

·       For the values of time intervals related to the processing latency of the Ambient IoT device, such as TDL-UL and TDL-DL, the values from ISO 18000-6C UHF RFID are a reference for further study.

·       For the value of time intervals related to the processing latency of the BS, such as TUL-DL, the impact on the existing BS implementation is included in the study.

Decision: The document is noted.

R1-2400373         Discussions on frame structure and timing aspects for A-IoT              Intel Corporation

·       RAN1 to study aligned DL transmission for A-IoT system with NR.

·       RAN1 to study asynchronous UL transmission for A-IoT.

·       RAN1 to study the necessity of uplink synchronization for A-IoT system.

·       RAN1 to study random access procedure for A-IoT, including the following aspects:

o   Slot-ALOHA based approach can be considered as a starting point.

o   Backoff indication is broadcast to a group of A-IoT devices.

o   Contention resolution ID is carried in the initial uplink message for random access.

o   A-IoT devices randomly generate a backoff counter based on indicated backoff values for random access.

·       RAN1 to study control information for DL scheduling for A-IoT system.

·       RAN1 to study acknowledgement feedback in response to DL data transmission and corresponding transmission timing for A-IoT system.

·       RAN1 to study control information for UL scheduling for A-IoT system.

·       RAN1 to study UL transmission timing for A-IoT system.

Decision: The document is noted.

R1-2400059         Discussion on frame structure and timing aspects for Ambient IoT              Spreadtrum Communications

R1-2400078         Frame structure and timing aspects for Ambient IoT   Ericsson

R1-2400090         Discussion on frame structure and timing aspects for Ambient IoT devices  FUTUREWEI

R1-2400200         Discussion on frame structure and timing aspects for ambient IoT              Lenovo

R1-2400247         Discussion on Frame structure, random access, scheduling and timing aspects      vivo

R1-2400305         Discussion on frame structure and timing aspects for Ambient IoT              TCL

R1-2400332         Discussion on frame structure and timing aspects for Ambient IOT        CMCC

R1-2400364         Initial views on Frame structure and timing aspects for Ambient IoT         Nokia, Nokia Shanghai Bell

R1-2400438         Study of Frame structure and timing aspects for Ambient IoT              CATT

R1-2400460         Discussion on frame structure and timing for ambient IoT              NEC

R1-2400489         Discussion on frame structure and physical layer procedure for Ambient IoT        ZTE, Sanechips

R1-2400563         Discussion on frame structure and timing aspects for Ambient IoT              xiaomi

R1-2400612         Initial considerations on frame structure and timing aspects of A-IoT communication           OPPO

R1-2400631         Discussion on frame structure and timing aspects       Sharp

R1-2400664         Discussion on frame structure and timing aspects for Ambient IoT              China Telecom

R1-2400737         Considerations for frame structure and timing aspects Samsung

R1-2400778         Discussion on frame structure and timing     Fujitsu

R1-2400784         Discussion on frame structure and timing aspects for Ambient IoT              BUPT

R1-2400799         The frame structure consideration for Ambient IoT     Comba

R1-2400858         Frame structure and timing aspects for Ambient IoT   Sony

R1-2400954         Frame structure and timing aspects of Ambient IoT    InterDigital, Inc.

R1-2401017         Views on frame structure, synchronization, random access and timing for AIoT   Apple

R1-2401062         Discussion on A-IoT Frame Structure and Timing Aspects              Panasonic

R1-2401066         Ambient IoT: Frame structure and timing aspects       China Unicom

R1-2401120         Study on frame structure and timing aspects for Ambient IoT              NTT DOCOMO, INC.

R1-2401157         Discussion on Frame Structure and Timing Aspects for Ambient IoT         Indian Institute of Tech (M), IIT Kanpur

R1-2401231         Discussion on frame structure for ambient IoT            ETRI

R1-2401259         Discussion on frame structure and timing aspects       Google

R1-2401266         Discussion on      Frame structure and timing aspects IIT Kanpur, Indian Institute of Tech (M)

R1-2401277         Discussion on Frame structure and timing aspects      CEWiT

R1-2401309         On frame structure and timing aspects for A-IoT         MediaTek Inc.

R1-2401329         Frame structure and timing aspects for Ambient IoT   LG Electronics

R1-2401402         Discussion on frame structure and timing aspects for Ambient IoT              Sequans Communications

R1-2401446         Frame structure and timing aspects Qualcomm Incorporated

R1-2401541         FL summary #1 on frame structure and timing aspects for Rel-19 Ambient IoT         Moderator (vivo)

From Wednesday session

Agreement

From RAN1 perspective, at least when a response is expected from multiple devices that are intended to be identified, an A-IoT contention-based access procedure initiated by the reader is used.

Agreement

For A-IoT contention-based access procedure, at least slotted-ALOHA based access is studied.

Agreement

At least the following time domain frame structure is studied for A-IoT R2D and D2R transmission.

• For R2D transmission,
• A R2D timing acquisition signal (e.g. R2D preamble) is included at least for timing acquisition and for indicating the start of the R2D transmission in time domain.
• For D2R transmission,
• A D2R timing acquisition signal (e.g. D2R preamble) is included at least for timing acquisition and for indicating the start of the D2R transmission in time domain.
• FFS other necessary component(s), e.g. midamble, postamble, periodic sync signal, control fields, guard period

R1-2401789         FL summary #2 on frame structure and timing aspects for Rel-19 Ambient IoT         Moderator (vivo)

From Thursday session

Agreement

For further discussion, the following terminologies are used for A-IoT for studying processing time aspects:

• T_{R2D_min}: Minimum Time between a R2D transmission and the corresponding D2R transmission following it.
• T_{D2R_min}: Minimum Time between a D2R transmission and the corresponding R2D transmission following it.
• T_{R2D_R2D_min}: Minimum Time between two different consecutive R2D transmissions to the same A-IoT device.
• T_{D2R_D2R_min}: Minimum Time between two different consecutive D2R transmissions from the same A-IoT device.
• The study should consider at least following aspects
• Implementation restrictions for the existing BS/UE
• [Processing time is common or different for different A-IoT devices]
• [Processing time for different traffic types/command types (e.g. DT or DO-DTT) and/or different use case (e.g., Inventory or Command)]
• FFS other timing aspects

Final summary in R1-2401849.

9.4.2.3       Downlink and uplink channel/signal aspects

Including detailed physical layer design aspects such as information payload, time/frequency domain resource, feasibility and required functionalities for proximity determination, etc.

R1-2400490         Discussion on downlink and uplink channel and signal  for Ambient IoT       ZTE, Sanechips

·       For A-IoT downlink channel, only PDSCH is needed, where the two types of PDSCH can be considered, i.e., PDSCH type 1 for DL data and PDSCH type 2 for control information.

·       Reference signal(s) are needed to provide synchronization, de-modulation information or other information, if any, which includes transmission types

·       The following three options can be used to indicate the end/duration of DL data transmission:

o   Option #1: Based on TBS information

o   Option #2: Terminator

o   Option #3: Combination of Option 1 and Option 2.

·       The available downlink frequency domain resource of A-IoT system can be located near to or in the guard band.

·       Support PUSCH in A-IoT system.

·       Synchronization signal and reference signal used for de-modulation/channel estimation can be considered in the UL of A-IoT system. Other information, such as uplink encoding information, can be also conveyed by the synchronization signal and reference signal, if needed.

·       The following three options can be used to indicate the end/duration of UL data transmission:

o   Option #1: Based on TBS information

o   Option #2: Terminator

o   Option #3: Combination of Option 1 and Option 2.

·       The available uplink frequency domain resource in A-IoT system can be located near to or in the guard band.

Decision: The document is noted.

R1-2401447         Downlink and uplink channel/signal aspects           Qualcomm Incorporated

·       Consider TDM between FL control and FL/BL data.

o   FFS: mapping to same or different physical channels for FL control and FL data

o   FFS: time gap between control and data

·       Study FL/BL control at least for dynamic FL and BL data scheduling for DO-DTT and DT.

o   FFS: other scheduling

·       Study broadcast/multicast/unicast for control and data of A-IoT communications.

·       For time/freq resource allocation of A-IoT communications

o   For Topology 1: BS configures FL/BL time/freq resources for A-IoT

§  BS/reader to control dynamic FL/BL within the configured time/freq resources.

o   For Topology 2: BS configures the time/freq resources per the UE/reader via Uu, at least for inband/guardband operation.

§  FFS: UE/reader or BS to control dynamic FL/BL within the configured time/freq resources

§  FFS: how to solve collision among UEs/readers for a shared resource

·       Study whether/how to apply power control for A-IoT devices and UE/reader.

·       Study scrambling for identification and interference randomization of control and data.

·       Study CRC length and association with the ID of reader and/or A-IoT device(s).

o   FFS: separate CRC for control and data.

·       Study A-IoT device measurement or reader measurement for proximity determination.

Decision: The document is noted.

R1-2400060              Discussion on downlink and uplink channel/signal aspects for Ambient IoT              Spreadtrum Communications

R1-2400079         Downlink and uplink channel/signal aspects for Ambient IoT              Ericsson

R1-2400091         Discussion on DL and UL channel/signal aspects for Ambient IoT devices  FUTUREWEI

R1-2400117         Physical channels and signals for Ambient IoT            Huawei, HiSilicon

R1-2400188         Discussion on downlink and uplink channel/signal aspects              TCL

R1-2400201         Discussion on downlink and uplink channel/signal aspects for ambient IoT         Lenovo

R1-2400248         Discussion on  Downlink and uplink channel/signal aspects              vivo

R1-2400333         Discussion on downlink and uplink channel/signal aspects              CMCC

R1-2400365         Initial views on Downlink and uplink channel/signal aspects for Ambient IoT        Nokia, Nokia Shanghai Bell

R1-2400439         DL and UL Physical Channels/signals design in support of Ambient IoT devices         CATT

R1-2400461         Discussion on downlink and uplink channel for ambient IoT              NEC

R1-2400564         Discussion on downlink and uplink channel/signal aspects for Ambient IoT        xiaomi

R1-2400613         Discussion on downlink and uplink channel/signal aspects for A-IoT         OPPO

R1-2400632         Discussion on downlink and uplink channel/signal aspects              Sharp

R1-2400665         Discussion on downlink and uplink channel/signal aspects for Ambient IoT        China Telecom

R1-2400738         Considerations for downlink and uplink channel/signal aspect              Samsung

R1-2400779         Discussion on downlink and uplink channel/signal     Fujitsu

R1-2400800         The downlink and uplink channel consideration for Ambient IoT              Comba

R1-2400812         Discussion on Downlink and Uplink Channel/Signal Aspects for A-IoT     EURECOM

R1-2400859         Downlink and uplink physical channel for Ambient IoT              Sony

R1-2400890         Discussion on downlink and uplink channels and signals for A-IoT         Panasonic

R1-2400955         Downlink and uplink channels aspects of Ambient IoT              InterDigital, Inc.

R1-2401018         Views on DL and UL PHY channels/signals and proximity determination for AIoT      Apple

R1-2401067         Ambient IoT: Downlink and uplink channel/signal aspects              China Unicom

R1-2401121         Study on downlink and uplink channel/signal aspects for Ambient IoT         NTT DOCOMO, INC.

R1-2401260         Discussion on downlink and uplink transmission aspects              Google

R1-2401283         Discussion on Downlink and uplink channel/signal aspects      IIT Kanpur, Indian Institute of Tech (M)

R1-2401310         On downlink and uplink channel/signal aspects for A-IoT              MediaTek Inc.

R1-2401330         Downlink and uplink channel/signal aspects for Ambient IoT   LG Electronics

R1-2401401         Discussion on DL and UL channel/signal aspects for Ambient IoT              Sequans Communications

R1-2401729         Feature lead summary#1 on downlink and uplink channel/signal aspects   Moderator (Apple)

From Wednesday session

Agreement

For ambient IoT devices, a dedicated physical broadcast channel for R2D, e.g. PBCH-like, is not considered for study.

Agreement (amended as shown in Thursday session)

For ambient IoT devices, at least for R2D data transmission, a physical channel (PR2DCH) is studied,

• System information (if defined) is transmitted on the PR2DCH
• FFS Whether/how control information is transmitted on the PR2DCH
• Note: the naming of PR2DCH is used for the sake of the study

R1-2401799         Feature lead summary#2 on downlink and uplink channel/signal aspects     Moderator (Apple)

From Thursday session

Agreement

For ambient IoT devices, at least for D2R data transmission, a physical channel (PDRCH) is studied along with the following,

• Response transmitted from device to reader during contention-based access procedure is transmitted on the PDRCH
• FFS: Details of response
• FFS Whether/how/what D2R control information (if defined) is transmitted on the PDRCH
• Note: the naming of PDRCH is used for the sake of the study

Final summary in R1-2401857.

9.4.2.44       Waveform characteristics of carrier-wave provided externally to the Ambient IoT device

Including interference handling at Ambient IoT UL receiver and at NR base station

R1-2400249         Discussion on CW waveform and interference handling at AIoT UL receiver             vivo

·       Consider Single tone RF signal as carrier wave for backscatter transmission.

·       Prioritize CW transmission on FDD UL spectrum in R19 SI.

·       Consider the following methods to suppress interference cause by carrier wave in backscatter communication.

o   Spatial isolation, including introduce carrier wave source outside connection topology.

o   RF/analog domain interference cancellation before LNA.

o   Analog baseband filters before ADC.

Decision: The document is noted.

R1-2401122         Study on waveform characteristics of carrier-wave for Ambient IoT       NTT DOCOMO, INC.

·       Study following waveforms for carrier wave.

o   Option 1: Continuous sine wave at single frequency with constant amplitude.

o   Option 2: Power optimized waveform with repeated bursts of peak power.

o   E.g., Sine wave at multiple subcarriers.

o   E.g., Intermittent sine wave.

·       For spectrum of carrier wave and backscattering in topology 1, study following cases:

o   carrier wave is transmitted on DL band, backscattering transmission on UL band.

o   carrier wave is transmitted on UL band, backscattering transmission on UL band.

·       For spectrum of carrier wave and backscattering in topology 2, study following cases:

o   carrier wave is transmitted on DL band, backscattering transmission on UL band.

o   carrier wave is transmitted on UL band, backscattering transmission on UL band.

Decision: The document is noted.

R1-2400061         Discussion on waveform characteristics of external carrier-wave for Ambient IoT   Spreadtrum Communications

R1-2400080         Waveform characteristics of carrier wave provided externally to the Ambient IoT device     Ericsson

R1-2400092         Discussion on external carrier waveform characteristics for Ambient IoT devices         FUTUREWEI

R1-2400118         On external carrier wave for backscattering based Ambient IoT device    Huawei, HiSilicon

R1-2400190         Discussion on waveform characteristics of external carrier-wave for Ambient IoT   TCL

R1-2400202         Discussion on external carrier wave for ambient IoT   Lenovo

R1-2400334         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             CMCC

R1-2400366         Initial views on Waveform characteristics of carrier-wave provided externally to the Ambient IoT device            Nokia, Nokia Shanghai Bell

R1-2400386 Backscatter Scheme for Same Frequency Interference Avoidance and Image Interference Suppression              BJTU

R1-2400440         Discussion on the waveform characteristics of carrier-wave for the Ambient IoT device     CATT

R1-2400491         Discussion on carrier wave for Ambient IoT ZTE, Sanechips

R1-2400565         Discussion on waveform characteristics of carrier-wave              xiaomi

R1-2400614         Discussion on Waveform characteristics of carrier-wave provided externally to the A-IoT device         OPPO

R1-2400633         Discussion on waveform characteristics of externally provided carrier-wave        Sharp

R1-2400666         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             China Telecom

R1-2401481         Considerations for Waveform characteristics of carrier-wave              Samsung              (rev of R1-2400739)

R1-2400860         External carrier wave for Ambient IoT          Sony

R1-2401019         Views on carrier waveform and interference handling for AIoT              Apple

R1-2401158         Discussion on Waveform Characteristics of External Carrier Wave in Ambient IoT        Indian Institute of Tech (M), IIT Kanpur

R1-2401184         Carrier-wave design for Ambient IoT            InterDigital, Inc.

R1-2401261         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             Google

R1-2401278         Discussion on Waveform characteristics of carrier-wave provided externally to the Ambient IoT device             CEWiT

R1-2401311         On carrier-wave waveform characteristics for A-IoT   MediaTek Inc.

R1-2401331         Consideration points on carrier-wave transmission for Ambient IoT         LG Electronics

R1-2401448         Waveform characteristics of carrier-wave provided externally to the Ambient IoT device     Qualcomm Incorporated

R1-2401695         FL summary#1 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

R1-2401788         FL summary#2 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

From Thursday session

Agreement

For R19 A-IoT study item, at least single-tone unmodulated sinusoid waveform is a candidate waveform for carrier wave for D2R backscattering.

Agreement

For R19 A-IoT study item, multi-tone waveforms for carrier wave for D2R backscattering can be studied.

Agreement

For the case that D2R backscattering is transmitted in the same carrier as CW for D2R backscattering, and for topology 1, the following cases for CW transmission are studied.

·       Case 1-1: CW is transmitted from inside the topology, transmitted in DL spectrum

·       Case 1-2: CW is transmitted from inside the topology, transmitted in UL spectrum

·       Case 1-4: CW is transmitted from outside the topology, transmitted in UL spectrum

Agreement

For the case that D2R backscattering is transmitted in the same carrier as CW for D2R backscattering, and for topology 2, the following cases for CW transmission are studied.

·       Case 2-2: CW is transmitted from inside the topology (i.e., intermediate UE), transmitted in UL spectrum

·       Case 2-3: CW is transmitted from outside the topology, transmitted in DL spectrum

·       Case 2-4: CW is transmitted from outside the topology, transmitted in UL spectrum

Final summary in R1-2401855.

 RAN1#116-bis

9.4      Study on solutions for Ambient IoT (Internet of Things) in NR

Please refer to RP-240826 for detailed scope of the SI. For additional clarification on the work scope, please refer to section 8 of RP-240854.

R1-2403663         Session notes for 9.4 (Study on solutions for Ambient IoT in NR)       Ad-Hoc Chair (Huawei)

Friday decision: The session notes are endorsed and contents reflected below.

[116bis-R19-A_IoT] – Xiaodong (CMCC)

Email discussion on Rel-19 Ambient IoT

-        To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

9.4.1       Evaluation on Ambient IoT in NR

9.4.1.1       Evaluation assumptions and results

Including assumptions on coverage and coexistence evaluations, link budget calculations, and remaining design targets of TR 38.848

R1-2401970         Evaluation assumptions and results for Ambient IoT   Ericsson

R1-2402011         Evaluation methodology and assumptions for Ambient IoT              Huawei, HiSilicon

R1-2402040         Discussion on evaluation assumptions and results for Ambient IoT devices          FUTUREWEI

R1-2402072         Evaluation assumptions and results for Ambient IoT   Nokia

R1-2402105              Discussion on evaluation assumptions and results for Ambient IoT              Spreadtrum Communications

R1-2402137         Discussions on deployment scenarios and evaluation assumptions for A-IoT             Intel Corporation

R1-2402184         Discussion on Ambient IoT evaluations        ZTE, Sanechips

R1-2402242         Evaluation methodologies assumptions and results for Ambient IoT         vivo

R1-2402328         Discussion on evaluation assumptions and results for A-IoT              OPPO

R1-2402383         The evaluation methodology and preliminary results of Ambient IoT         CATT

R1-2402466         Considerations for evaluation assumptions and results              Samsung

R1-2402510         Discussion on evaluation assumptions and results for Ambient IoT         China Telecom

R1-2402565         Discussion on evaluation methodology and assumptions              CMCC

R1-2402666         Evaluation methodology and assumptions for Ambient IoT              Xiaomi

R1-2402826         Discussion on ambient IoT evaluation framework       NEC

R1-2402857         Evaluation assumptions for Ambient IoT       InterDigital, Inc.

R1-2402881         Views on evaluation assumptions and link budget analysis for AIoT      Apple

R1-2402946         On evaluation assumptions and results for A-IoT        MediaTek

R1-2402967         Evaluation assumptions and results for Ambient IoT   Sony

R1-2403117         Discussion on Ambient IoT evaluation          LG Electronics

R1-2403194         Evaluation Assumptions and Results             Qualcomm Incorporated

R1-2403244         Study on evaluation assumptions for Ambient IoT      NTT DOCOMO, INC.

R1-2403284         Evaluation assumptions for Ambient IoT       Comba

R1-2403397         Discussion on Evaluation assumption and preliminary results for AIoT      IIT Kanpur, Indian Institute of Technology Madras

R1-2403515         FL summary #1 for Ambient IoT evaluation           Moderator (CMCC)

From Monday session

Agreement

For R2D link in the coverage evaluation, for device 1

• Budget-Alt1 is used (note: receiver architecture is RF ED)

For D2R link in the coverage evaluation,

• Budget-Alt2 is used.

Agreement

The following scenarios are defined,

·       FFS: which of these scenarios will be evaluated.

R1-2403516         FL summary #2 for Ambient IoT evaluation           Moderator (CMCC)

From Tuesday session

Agreement

For D1T1,

·       InF-DH NLOS model defined in TR38.901 is used for D2R and R2D links as pathloss model in coverage evaluation.

For D2T2,

·       InF-DL and InH-Office model defined in TR38.901is used as pathloss model in coverage evaluation,

o   NLOS for D2R and R2D links if InF-DL is used

o   LOS for D2R and R2D links if InH-Office is used

Agreement

The following layout is used for evaluation purpose,

·       FFS: CW distribution for D1T1-B and D2T2-B

Agreement

In the link level simulation, considering the following channel model,

·       For D1T1, TDL-A channel model is used for R2D link and for D2R link for InF-DH scenario.

·       For D2T2,

o   TDL-A channel model is used for R2D link and for D2R link if InF scenario is considered

o   TDL-D channel model is used for R2D link and for D2R link if InH-Office scenario is considered

·       FFS delay spread for each case.

Agreement

For coverage evaluation, subject to further discussion on which scenarios to evaluate,

·       In the case of CW inside topology with ’A2’ scenarios

o   The digital baseband processing of CW self-interference handling is not modelled in link level simulation (LLS). It is included in the link budget analysis by reporting the CW cancellation capability value.

·       FFS: In the case of CW outside topology with ‘B’ scenarios or CW inside topology with ’A1’ scenarios

Agreement

The maximum distance targets are set separately for device 1, device 2a, device 2b, respectively

·       FFS detailed values and RAN1 can further decide the target within in the range of 10m to 50m after link budget study.

·       FFS whether to set different values for different scenarios

R1-2403643         FL summary #3 for Ambient IoT evaluation           Moderator (CMCC)

From Thursday session

Agreement

The table below is agreed (except for the yellow part)

<Editor Notes: Note 1 will be updated once the table has stabilized >

Note1: calculated values in the Table XXXX are derived according to the followings,

• 1E
• For D2R, and device 1/2(backscatter), whether this value is need (not regarded as an input variable but regarded as indirect variable), or based on backscatter activation power threshold
• 1M
• For R2D,  
• For D2R,
• Device 1:
• Device 2a:
• Device 2b:
• 2F:
• 2L
• For R2D and Budget-Alt1, [2L] = [2H]
• For R2D and Budget-Alt2, [2L] = [2G]+[2F]
• For D2R and Budget-Alt2, Refer to section [xxx] (Proposal [P4-3])
• 4A
• 
• 4B is derived from pathloss model
• Refer to section [XXX] (Proposal [P4-3-2])

Note2: (M) denotes the value is mandatory to be evaluated. (O) denotes the value can be optionally evaluated.

R1-2403768         FL summary #4 for Ambient IoT evaluation           Moderator (CMCC)

From Friday session

Agreement

For coverage evaluation purpose,

• For scenarios ‘A1’ and ‘A2’,
• The Device Tx Power is calculated by assuming CW2D pathloss = D2R pathloss.
• For scenarios ‘B’,
• The Device Tx Power is calculated by CW received power which can be derived by at least CW2D distance (m) value.
• FFS: CW2D distance (m) value(s)

R1-2403769         [draft] LS on Ambient-IoT evaluation scenarios and assumptions       CMCC, [RAN1]

Decision: The draft LS in R1-2403769 is endorsed with the following changes:

-          For the last agreement copied in the LS, remove the green highlight in the second column and delete “note 1” with its yellow highlights.

-          Revise the first sentence in the LS as follows:

o     RAN1 has discussed and agreed the following aspects. RAN1 would like to clarify that parts highlighted in yellow are not yet agreed by RAN1.

-          Revise the action to RAN4 as follows:

o     RAN1 respectfully asks RAN4 to take the above information into account for coexistence studies and to provide a response if needed.

Friday decision: Final LS is approved in R1-2403782. Note the above additional agreement reached on Friday is added in the LS compare to the endorsed draft LS in R1-2403769.

[Post-116bis-AIoT] Email discussion on Ambient IoT evaluation assumptions from April 23 until April 26 – Xiaodong (CMCC)

·       focus on proposals P3.7.1-v1, P3.5.8-v2, P3.2.1-(1)-v2 and P3.5.5-v1 in section 2 of R1-2403768.

Friday decision: Focus on proposal P3.2.4-v1 in section 2 of R1-2403768 is added to the post email discussion.

Final summary in R1-2403788.

9.4.1.2       Ambient IoT device architectures

R1-2401971         Ambient IoT device architectures   Ericsson

R1-2401976         Discussion on ambient IoT device architectures          TCL

R1-2402012         Ultra low power device architectures for Ambient IoT              Huawei, HiSilicon

R1-2402041         Discussion on Ambient IoT device architectures              FUTUREWEI

R1-2402073         Ambient IoT device architectures   Nokia

R1-2402106         Discussion on Ambient IoT device architectures         Spreadtrum Communications

R1-2402185         Discussion on Ambient IoT device architectures         ZTE, Sanechips

R1-2402243         Discussion on Ambient IoT Device architectures        vivo

R1-2402329         Discussion on device architecture for A-IoT device    OPPO

R1-2402384         Study of the Ambient IoT devices architecture            CATT

R1-2402467         Considerations for Ambient-IoT device architectures Samsung

R1-2402511         Discussion on Ambient IoT device architectures         China Telecom

R1-2402566         Discussion on Ambient IoT device architectures         CMCC

R1-2402667         Discussion on ambient IoT device architectures          Xiaomi

R1-2402725         Discussion on Ambient IoT device architectures         Honor

R1-2402827         Device architecture requirements for ambient IoT       NEC

R1-2402858         Device architectures for Ambient IoT            InterDigital, Inc.

R1-2402882         Views on device architecture for AIoT          Apple

R1-2402947         On Ambient IoT device architectures            MediaTek

R1-2402968         Ambient IoT device architectures   Sony

R1-2403059         Discussion on Ambient IoT device architectures         CEWiT

R1-2403102         Discussion on the Ambient IoT device architectures   Lenovo

R1-2403118         Discussion on Ambient IoT device architectures         LG Electronics

R1-2403195         Ambient IoT Device Architecture   Qualcomm Incorporated

R1-2403245         Study on device architecture for Ambient IoT             NTT DOCOMO, INC.

R1-2403398         Views on Architecture of Ambient IoT          IIT Kanpur, Indian Institute of Tech Madras

R1-2403497         FL Summary #1 for 9.4.1.2 A-IoT Device Architecture              Moderator (Qualcomm)

From Tuesday session

Agreement

Study device 2b architecture w/ RF-ED receiver with following blocks.

• Antenna could be either shared or separate for RF energy harvester (if present) and receiver/transmitter.
• Matching network is to match impedance between antenna and other components (including RF energy harvester (if present) and receiver related blocks).
• Energy harvester for harvesting energy from e.g., RF signal, solar, vibration/movement, temperature difference, etc
• Energy storage (e.g., capacitor) stores harvested energy from energy harvester.
• Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.
• Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
• Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.
• Clock generator provides required clock signal(s).
• Reception related blocks
• RF BPF filter for improving selectivity.
• Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak power consumption target also need to be considered.
• FFS: LNA for improving signal strength and sensitivity of receiver, if present
• RF envelope detector (RF-ED) detects envelope from RF signal.
• BB amplifier amplifies BB signal to improve signal strength.

• BB LPF can filter out harmonics and high frequency components to improve input signal quality to comparator/ADC.
• Depending on implementation, it may not exist.

• Comparator or N-bit ADC
• Transmission related blocks

o   Tx Modulator: baseband bits are modulated according to modulation scheme. This block could be the part of BB logic.

o   Digital to Analog Converter (DAC) converts digital signal to analog signal.

o   Low pass filter for filtering out undesired signal

o   Mixer performs up converting baseband signal to RF range.

o   Local oscillator (LO) for carrier frequency generation

o   FFS: PLL/FLL

o   FFS: Power amplifier (PA) amplifies tx signal, if present

o   Details on transmitter related blocks depends on tx waveform/modulation.

Agreement

Further study reflection amplifier for Device 2a, considering following aspects:

·       Types of reflection amplifier

o   Uni-directional/one-way (for D2R)

o   Bi-directional/two-way (for both R2D and D2R)

§  FFS: switching loss (if applicable)

·       One-way Amplification Gain

o   E.g. [10, 15, 25] dB

o   Considering stability, operating frequency, and power consumption characteristics

·       Bandwidth

Agreement

Further study the feasibility of large frequency shift (large FS, i.e. between DL/UL spectrum of an FDD band) for device 2a considering at least following aspects.

• Power consumption characteristics
• Frequency shift range and granularity
• Image suppression or SSB backscatter for large FS

• IF carrier frequency accuracy
• Harmonics suppression

Note: the necessity (including applicable potential scenarios) of large FS can still be discussed in other agendas of the SI.

R1-2403498         FL Summary #2 for 9.4.1.2 A-IoT Device Architecture              Moderator (Qualcomm)

From Wednesday session

Agreement

Study device 2b architecture with ZIF receiver with following blocks.

• Antenna could be either shared or separate for RF energy harvester (if present) and receiver/transmitter.
• Matching network is to match impedance between antenna and other components (including RF energy harvester (if present) and receiver related blocks).
• Energy harvester for harvesting energy from e.g., RF signal, solar, vibration/movement, temperature difference, etc
• Energy storage (e.g., capacitor) stores harvested energy from energy harvester.
• Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.
• Digital BB logic includes functional blocks like encoder, detector, decoder, controller, etc.
• Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.
• Clock generator provides required clock signal(s).
• Local oscillator (LO) for generating carrier frequency for Tx and Rx
• FFS: PLL/FLL
• FFS: one LO or separate LOs for Tx and Rx
• Reception related blocks
• RF BPF filter for improving selectivity.
• Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak power consumption target also need to be considered.
• FFS: LNA for improving signal strength and sensitivity of receiver.
• Mixer down converts RF signal to BB stage.
• Depending on implementation, there could be one or two mixers for Rx and Tx
• BB amplifier amplifies BB signal

• BB LPF can filter out undesired frequency components to improve input signal quality to comparator/ADC.
• Depending on implementation, it may not exist.

• Comparator or N-bit ADC
• Transmission related blocks

o   Tx Modulator: baseband bits are modulated according to modulation scheme. This block could be the part of BB logic.

o   Digital to Analog Converter (DAC) converts digital signal to analog signal.

o   Low pass filter for filtering out undesired signal

o   Mixer performs up converting baseband signal to RF range.

o   FFS: Power amplifier (PA) amplifies tx signal, if present

o   Details on transmitter related blocks depends on e.g., waveform/modulation, etc

Agreement

Study device 2b architecture with IF-ED receiver with following blocks.

• Antenna could be either shared or separate for RF energy harvester (if present) and receiver/transmitter.
• Matching network is to match impedance between antenna and other components (including RF energy harvester (if present) and receiver related blocks).
• Energy harvester for harvesting energy from e.g., RF signal, solar, vibration/movement, temperature difference, etc
• Energy storage (e.g., capacitor) stores harvested energy from energy harvester.
• Power management unit (PMU) manages storing energy to energy storage from energy harvester and suppling power to active component blocks which needs power supply.
• Digital BB logic includes functional blocks like encoder, decoder, controller, etc.
• Memory can include two types of memory: 1) Non-Volatile Memory (NVM) such as EEPROM for permanently storing device ID, etc, and 2) registers for temporarily keeping any information required for its operation only while energy is available in energy storage.
• Clock generator provides required clock signal(s).
• Local oscillator (LO) for generating carrier frequency for Tx, or for generating carrier frequency offset by the IF for Rx
• FFS: PLL/FLL
• FFS: one LO or separate LOs for Tx and Rx
• Reception related blocks
• RF BPF filter for improving selectivity.
• Depending on implementation, it may not exist. RAN4 RF requirement (if any, e.g., ACS) and peak power consumption target also need to be considered.
• FFS: LNA for improving signal strength and sensitivity of receiver, if present
• Mixer down converts RF signal to IF stage.
• Depending on implementation, there could be one or two mixers for Rx and Tx
• IF amplifier amplifies IF signal
• IF filter for filtering out unwanted RF and LO signals
• IF envelope detector (IF-ED) detects envelope from IF signal.
• BB amplifier
• Depending on implementation, one or both of IF amplifier and BB amplifier may exist.

• BB LPF can filter out harmonics and high frequency components to improve input signal quality to comparator/ADC.
• Depending on implementation, it may not exist.

• Comparator or N-bit ADC
• Note: image rejection is required
• Transmission related blocks

o   Tx Modulator: baseband bits are modulated according to modulation scheme. This block could be the part of BB logic.

o   Digital to Analog Converter (DAC) converts digital signal to analog signal.

o   Low pass filter for filtering out undesired signal

o   Mixer performs up converting baseband signal to RF range.

o   FFS: Power amplifier (PA) amplifies tx signal, if present

o   Details on transmitter related blocks depends on e.g., waveform/modulation, etc

R1-2403499         FL Summary #3 for 9.4.1.2 A-IoT Device Architecture              Moderator (Qualcomm)

Final summary in R1-2403774.

9.4.2       Physical layer design for Ambient IoT

9.4.2.1       General aspects of physical layer design

Including numerologies, bandwidths, multiple access, waveform, modulation, and coding

R1-2401972         General aspects of physical layer design for Ambient IoT              Ericsson

R1-2401977         Discussion on general aspects of physical layer design for Ambient IoT        TCL

R1-2402013         On general aspects of physical layer design for Ambient IoT              Huawei, HiSilicon

R1-2402042         Discussion on physical layer design for Ambient IoT devices              FUTUREWEI

R1-2402074         General aspects of physical layer design for Ambient IoT              Nokia

R1-2402107         Discussion on general aspects of physical layer design for Ambient IoT   Spreadtrum Communications

R1-2403445         Discussion on general aspects of physical layer design for Ambient IoT        ZTE, Sanechips   (rev of R1-2402186)

R1-2402244         Discussion on General Aspects of Physical Layer Design              vivo

R1-2402330         Discussion on general aspects of physical layer design of A-IoT communication   OPPO

R1-2402385         Discussion on general aspects of physical layer design              CATT

R1-2402468         Considerations on general aspects of Ambient IoT      Samsung

R1-2402487         General aspects of physical layer design for Ambient IoT              Panasonic

R1-2402512         Discussion on general aspects of physical layer design for Ambient IoT        China Telecom

R1-2402547         Discussion on Physical Layer Design for Ambient-IoT              EURECOM

R1-2402567         Discussion on general aspects of A-IoT physical layer design              CMCC

R1-2402668         Discussion on physical layer design of Ambient IoT   Xiaomi

R1-2402706         Considerations on Some Aspects of Physical Layer Design for Ambient IoT        Continental Automotive

R1-2402720         Ambient IoT – General aspects of physical layer design, for uplink modulation             Wiliot Ltd.

R1-2402736         Discussion on general aspects of physical layer design              Sharp

R1-2402769         Discussion on general aspects of ambient IoT physical layer design    NEC

R1-2402859         Discussion on general aspects of physical layer design for Ambient IoT        InterDigital, Inc.

R1-2402883         Views on general physical layer design aspects for AIoT              Apple

R1-2402948         On general aspects of physical layer design for A-IoT MediaTek

R1-2402969         General aspects of physical layer design for Ambient IoT              Sony

R1-2403020         Discussion on general aspects of physical layer design              ETRI

R1-2403060         Discussion on General aspects of physical layer design              CEWiT

R1-2403069         Discussions on general aspects of physical layer design for Ambient IoT        Ruijie Networks Co. Ltd

R1-2403090         Discussion on general aspects of physical layer design              Google

R1-2403103         Discussion on the physical layer design aspects for Ambient IoT devices  Lenovo

R1-2403119         General aspects of Ambient IoT physical layer design LG Electronics

R1-2403196         General aspects of physical layer design       Qualcomm Incorporated

R1-2403246         Study on general aspects of physical layer design for Ambient IoT              NTT DOCOMO, INC.

R1-2403281         Discussion on general aspects of physical layer design              Comba   (Tdoc is withdrawn)

R1-2403309         General aspects of physical layer design for Ambient IoT              ITL

R1-2403394         Discussion on general aspects of physical layer design for AIoT              IIT Kanpur, Indian Institute of Technology Madras

R1-2403487         Feature Lead Summary#1 for 9.4.2.1: "Ambient IoT – General aspects of physical layer design"  Moderator (Huawei)

From Tuesday session

Agreement

Study time-domain multiple access of D2R transmissions. Further details, including pros/cons, are FFS.

Agreement

Study frequency-domain multiple access of D2R transmissions, at least by utilizing a small frequency-shift in baseband. Further details, including pros/cons, are FFS.

Agreement

Whether code-domain multiple access is feasible and necessary for D2R transmissions for all devices is FFS.

Agreement

The following bandwidths for D2R are defined for the purpose of the study:

• Transmission bandwidth, B_tx,D2R: The frequency resources scheduled by a reader for a D2R transmission from one device.
• FFS in agenda 9.4.2.3: how frequency resources scheduled by a reader are determined
• Occupied bandwidth, B_occ,D2R: The transmission bandwidth plus the potential associated intra A-IoT guard-bands totalling B_guard,D2R
• Note: this guard band is not for coexistence with NR/LTE
• If/how to define guard band for coexistence between A-IoT D2R and NR/LTE is up to RAN4.
• B_occ,D2R >= B_tx,D2R
• Possible values of each bandwidth are FFS

R1-2403488         Feature Lead Summary#2 for 9.4.2.1: "Ambient IoT – General aspects of physical layer design"  Moderator (Huawei)

From Wednesday session

Agreement

For D2R, study: Manchester encoding, FM0 encoding, Miller encoding, no line coding.

• FFS: Mapping(s) from bit(s) to line-code codewords
• FFS: How to achieve small frequency shift in baseband and/or FDM(A) among devices
• Aspects to study include:
• Spectrum shape
• Complexity
• Power consumption
• BER, BLER
• Resilience to SFO
• If there is any relation to CFO

Agreement

A-IoT D2R study of FEC includes at least convolutional codes.

• Comparisons are encouraged to compare to the case of no FEC
• FFS details of convolutional codes, such as polynomial(s), shift-register termination, etc.
• FFS if other FEC candidates/methods will be studied.

Agreement

Study

• baseline: using 6 bits and 16 bits CRC with polynomials from TS 38.212, or no CRC, for PRDCH
• baseline: using 6 bits and 16 bits CRC with polynomials from TS 38.212, or no CRC, for PDRCH
• FFS: details when different CRC lengths or no CRC may be used
• FFS: other 6 bits and 16 bits CRC with different polynomials than from TS 38.212

Agreement

Study D2R transmission in the physical layer using repetition

• Note: Discussions regarding higher-layer repetitions are up to RAN2.

R1-2403678         Feature Lead Summary#3 for 9.4.2.1: “Ambient IoT – General aspects of physical layer design”  Moderator (Huawei)

From Friday session

Agreement

R2D study includes subcarrier spacing of 15 kHz, from the reader perspective, for OFDM-based waveform.

• Inclusion in the study of subcarrier spacing of 30 kHz is FFS.

Agreement

For R2D study OFDM-based waveform with subcarrier spacing of 15 kHz, B_tx,R2D is ≤ [12] PRBs and is down-selected among:

• Alt 1: Including 180 kHz, 360 kHz, and FFS other values
• Alt 2: Integer multiple(s) of 180 kHz (FFS: what integer(s))
• Alt 3: Integer multiple(s) of the subcarrier spacing (FFS: what integer(s))

Agreement

For R2D CP handling for OFDM based OOK waveform:

• For potential down-selection, study among the following candidate methods
• Method Type 1: Removal of CP at device without specified transmit-side
• FFS: How device determines the CP location
• FFS: Impact on feasibility of device SFO
• FFS: relation to M, if any
• Method Type 2: Ensure the CP insertion of OFDM-based waveform will not introduce false rising/falling edge between the last OOK chip in OFDM symbol (n-1) and the first OOK chip in OFDM symbol n.
• FFS: Whether/how to arrange that OOK chips have equal length after CP insertion
• FFS: relation to M, if any
• FFS: Detail of relationship to line code codewords
• FFS: Impact on feasibility of device SFO
• [Other method types are not precluded]
• Study of the methods should include e.g.:
• CP impact on R2D timing acquisition, and decoding & performance of PRDCH
• Reader and device implementation complexities
• Interference between R2D and NR DL/UL if in the same NR band
• Spectrum efficiency

Agreement

Study for all devices the following for D2R baseband modulation, for potential down-selection:

• OOK
• Binary PSK
• Binary FSK
• Strive to identify one variant of Binary FSK to study further.

Final summary in R1-2403679.

9.4.2.2       Frame structure and timing aspects

Including synchronization and timing, random access, scheduling and timing relationships

R1-2401973         Frame structure and timing aspects for Ambient IoT   Ericsson

R1-2402014         On frame structure and timing aspects of Ambient IoT              Huawei, HiSilicon

R1-2402043         Discussion on Frame Structure and Timing Aspects for Ambient IoT         FUTUREWEI

R1-2402075         Frame structure and timing aspects for Ambient IoT   Nokia

R1-2402108         Discussion on frame structure and timing aspects for Ambient IoT              Spreadtrum Communications

R1-2402134         Discussions on frame structure and timing aspects for A-IoT              Intel Corporation

R1-2402154         Discussion on frame structure and timing aspects for Ambient IoT              BUPT    (Late submission)

R1-2402187         Discussion on frame structure and physical layer procedure for Ambient IoT        ZTE, Sanechips

R1-2402245         Discussion on Frame structure, random access, scheduling and timing aspects      vivo

R1-2402331         Discussion on frame structure and timing aspects of A-IoT              OPPO

R1-2402386         Study of Frame structure and timing aspects for Ambient IoT              CATT

R1-2402469         Considerations for frame structure and timing aspects Samsung

R1-2402513         Discussion on frame structure and timing aspects for Ambient IoT              China Telecom

R1-2402568         Discussion on frame structure and timing aspects for A-IoT              CMCC

R1-2402585         Discussion on physical layer procedures for ambient IoT              Lenovo

R1-2402615         Frame structure and timing aspects of Ambient IoT    InterDigital, Inc.

R1-2402669         Discussion on frame structure and timing aspects for Ambient IoT              Xiaomi

R1-2402737         Discussion on frame structure and timing aspects       Sharp

R1-2402748         Discussion on A-IoT Frame Structure and Timing Aspects              Panasonic

R1-2402770         Discussion on frame structure and timing for ambient IoT              NEC

R1-2402796         Discussion on frame structure and timing aspects       Fujitsu

R1-2402884         Frame structure and timing aspects for Ambient IoT   Apple

R1-2402949         On frame structure and timing aspects for A-IoT         MediaTek

R1-2402970         Frame structure and timing aspects for Ambient IoT   Sony

R1-2403021         Discussion on frame structure and timing aspects       ETRI

R1-2403038         Discussion on frame structure and timing aspects for AIoT              TCL

R1-2403042         Discussion on frame structure and timing aspects for Ambient IoT              Comba

R1-2403061         Discussion on Frame structure and timing aspects      CEWiT

R1-2403091         Discussion on frame structure and timing aspects       Google

R1-2403120         Frame structure and timing aspects for Ambient IoT   LG Electronics

R1-2403197         Frame structure and timing aspects Qualcomm Incorporated

R1-2403247         Study on frame structure and timing aspects for Ambient IoT              NTT DOCOMO, INC.

R1-2403373         Discussion on Frame structure and timing aspects for A-IoT              China Unicom

R1-2403393         Discussion on Frame Structure and Timing Aspects for Ambient IoT         Indian Institute of Tech (M), IIT Kanpur

R1-2403395         Discussion on Frame structure and timing aspects for AIoT      IIT Kanpur, Indian Institute of Technology Madras

R1-2403446         FL summary #1 on frame structure and timing aspects for Rel-19 Ambient IoT         Moderator (vivo)

From Tuesday session

Agreement

For R2D transmission, if OFDM-based waveform is used, the start of R2D transmission from reader perspective is assumed to be aligned with the boundary of an NR OFDM symbol (including the CP) for in-band/guard-band operation.

R1-2403447         FL summary #2 on frame structure and timing aspects for Rel-19 Ambient IoT         Moderator (vivo)

From Thursday session

Agreement

To determine or derive the end of PRDCH transmission, study at least following options:

·       Option 1: R2D postamble immediately follows the PRDCH to indicate the end of the PRDCH.

·       Option 2: Based on R2D control information.

Agreement

For the reader to acquire the end of PDRCH transmission, study at least following options:

·       Option 1: D2R postamble immediately follows the PDRCH

·       Option 2: Based on control information

Agreement

For D2R transmission, study the necessity of midamble at least for the purpose of performing timing/frequency tracking or channel estimation or interference estimation, considering at least the following:

·       Modulation and Coding schemes, e.g., data modulation, line/channel coding

·       Receiving methods, e.g., coherent or non-coherent

·       D2R transmission length/packet size

·       Midamble overhead

·       Timing/frequency accuracy

·       Phase accuracy

R1-2403448         FL summary #3 on frame structure and timing aspects for Rel-19 Ambient IoT         Moderator (vivo)

From Friday session

Agreement

RAN1 study the R2D transmission without midamble as the baseline if Manchester encoding is used.

·       FFS the necessity for the R2D transmission with midamble if PIE is used.

Final summary in R1-2403776.

9.4.2.3       Downlink and uplink channel/signal aspects

Including detailed physical layer design aspects such as information payload, time/frequency domain resource, feasibility and required functionalities for proximity determination, etc.

R1-2401974         Downlink and uplink channel/signal aspects for Ambient IoT              Ericsson

R1-2401978         Discussion on downlink and uplink channel/signal aspects for Ambient IoT        TCL

R1-2402015         Physical channels and signals for Ambient IoT            Huawei, HiSilicon

R1-2402044         Discussion on D2R and R2D Channel/Signal Aspects for Ambient IoT         FUTUREWEI

R1-2402076         R2D and D2R channel/signal aspects for Ambient IoT              Nokia

R1-2402109              Discussion on downlink and uplink channel/signal aspects for Ambient IoT              Spreadtrum Communications

R1-2402135         Discussions on physical channel and signals for A-IoT              Intel Corporation

R1-2402188         Discussion on downlink/uplink channel/signal  for Ambient IoT              ZTE, Sanechips

R1-2402246         Discussion on  Downlink and uplink channel/signal aspects              vivo

R1-2402332         Discussion on downlink and uplink channel/signal aspects for A-IoT         OPPO

R1-2402387         DL and UL Physical Channels/signals design in support of Ambient IoT devices         CATT

R1-2402470         Considerations for downlink and uplink channel/signal aspect              Samsung

R1-2402514         Discussion on downlink and uplink channel/signal aspects for Ambient IoT        China Telecom

R1-2402569         Discussion on downlink and uplink channel/signal aspects              CMCC

R1-2402586         Discussion on channel/signal aspects for ambient IoT Lenovo

R1-2402616         Downlink and uplink channels aspects of Ambient IoT              InterDigital, Inc.

R1-2402670         Discussion on downlink and uplink channel_signal aspects for Ambient IoT        Xiaomi

R1-2402705         Considerations on downlink and uplink channels/signals for A-IoT         Continental Automotive

R1-2402738         Discussion on downlink and uplink channel/signal aspects              Sharp

R1-2402771         Discussion on downlink and uplink channel for ambient IoT              NEC

R1-2402797         Discussion on downlink and uplink channel/signal aspects              Fujitsu

R1-2402856         Discussion on downlink and uplink channels and signals for A-IoT         Panasonic

R1-2402885         Views on physical channels/signals and proximity determination for AIoT Apple

R1-2402950         On downlink and uplink channel/signal aspects for A-IoT              MediaTek

R1-2402971         Downlink and uplink physical channel for Ambient IoT              Sony

R1-2403022         Discussion on downlink and uplink channel/signal aspects for A-IoT         ETRI

R1-2403043         Discussion on downlink and uplink channel and signal for Ambient IoT        Comba

R1-2403092         Discussion on downlink and uplink transmission aspects              Google

R1-2403121         Downlink and uplink channel/signal aspects for Ambient IoT   LG Electronics

R1-2403198         Downlink and uplink channel/signal aspects Qualcomm Incorporated

R1-2403248         Study on downlink and uplink channel/signal aspects for Ambient IoT         NTT DOCOMO, INC.

R1-2403374         Discussion on downlink and uplink channel aspects for A-IoT              China Unicom

R1-2403396         Discussion on Downlink and Uplink channel/signal aspects for AIoT      IIT Kanpur, Indian Institute of Technology Madras

R1-2403558         Feature lead summary#1 on downlink and uplink channel/signal aspects     Moderator (Apple)

From Wednesday session

Agreement

For the R2D timing acquisition signal immediately preceding the transmission of a physical channel, study a preamble with at least two parts which includes a start-indicator part and a clock-acquisition part, where the start-indicator part immediately precedes the clock-acquisition part:

• Start-indicator part provides the start of the R2D transmission
• FFS: Details of start-indicator part
• Clock-acquisition part provides at least the chip synchronization of the subsequent physical channel transmission
• FFS: Details of clock-acquisition part, e.g. structure, encoding, length, etc.
• FFS: Methods to determine chip duration of the subsequent physical channel transmission
• FFS: Other functionalities
• Note: the preamble is considered not to be part of a physical channel
• FFS: other part(s) of the preamble, if any
• FFS: whether the above clock acquisition is sufficient for all devices
• FFS: how to make the preamble compact

R1-2403637         Feature lead summary#2 on downlink and uplink channel/signal aspects     Moderator (Apple)

From Thursday session

Agreement

For D2R, a preamble preceding each PDRCH transmission is studied as the baseline at least for the D2R timing acquisition signal:

·       Preamble is not part of PDRCH

·       FFS: Other functionalities of the preamble

Agreement

For PRDCH generation at the reader, at least following blocks are studied as the baseline:

·       CRC bits are appended if there is non-zero length CRC

o   Note: CRC details discussed in agenda item 9.4.2.1

·       Line coding block

·       OOK-1/OOK-4 modulation with OFDM waveform generation, including resource mapping

o   FFS details

·       Note: Other blocks could be added if agreed

PRDCH generation

Agreement

For PDRCH generation at the device, at least following blocks are studied as the baseline:

·       CRC bits are appended if there is non-zero length CRC

o   Note: CRC details discussed in agenda item 9.4.2.1

·       Coding

o   Exact coding methods within the coding block, e.g. with/without line coding and/or FEC discussed under agenda 9.4.2.1

o   Note: If no line coding is used, there may be an additional block (e.g. square wave generator) before/after modulation block

·       Modulation

·       Note: Other blocks could be added if agreed

PDRCH generation

R1-2403749         Feature lead summary#3 on downlink and uplink channel/signal aspects     Moderator (Apple)

From Friday session

Agreement

Reference signals including at least DMRS, PTRS, CSI-RS/TRS, are not further studied for R2D.

Agreement

Reference signals including DMRS, PTRS, SRS, are not further studied for D2R

·       Note: This doesn’t preclude the possibility to study preamble, midamble, postamble for different purposes, e.g. channel/interference estimation and/or proximity determination

Agreement

Proximity determination based on device side measurements is not considered.

Final summary in R1-2403786.

9.4.2.44       Waveform characteristics of carrier-wave provided externally to the Ambient IoT device

Including interference handling at Ambient IoT UL receiver and at NR base station

R1-2401975         Waveform characteristics of carrier wave provided externally to the Ambient IoT device     Ericsson

R1-2401979         Discussion on waveform characteristics of external carrier-wave for Ambient IoT   TCL

R1-2402016         On external carrier wave for backscattering based Ambient IoT device    Huawei, HiSilicon

R1-2402045         Discussion on External Carrier Waveform Characteristics for Ambient IoT        FUTUREWEI

R1-2402077         Waveform characteristics of carrier-wave provided externally to the Ambient IoT device     Nokia

R1-2402110         Discussion on waveform characteristics of external carrier-wave for Ambient IoT   Spreadtrum Communications

R1-2402136         Discussions on waveform characteristics of carrier-wave for A-IoT         Intel Corporation

R1-2402189         Discussion on carrier wave for Ambient IoT ZTE, Sanechips

R1-2402247         Discussion on CW waveform and interference handling at AIoT UL receiver         vivo

R1-2402333         Discussion on Waveform characteristics of carrier-wave provided externally to the A-IoT device         OPPO

R1-2402388         Discussion on the waveform characteristics of carrier-wave for the Ambient IoT device     CATT

R1-2402471         Considerations for waveform characteristics of carrier-wave              Samsung

R1-2402515         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             China Telecom

R1-2402570         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             CMCC

R1-2402587         Discussion on external carrier wave for ambient IoT   Lenovo

R1-2402671         Discussion on waveform characteristics of carrier-wave              Xiaomi

R1-2402739         Discussion on waveform characteristics of externally provided carrier-wave        Sharp

R1-2402860         Discussion on carrier-wave for Ambient IoT InterDigital, Inc.

R1-2402886         Views on carrier waveform and interference handling for AIoT              Apple

R1-2402951         On carrier-wave waveform characteristics for A-IoT   MediaTek

R1-2402972         External carrier wave for Ambient IoT          Sony

R1-2403002         Discussion on waveform characteristics of carrier-wave for Ambient IoT device           Panasonic

R1-2403023         Discussion on waveform characteristics of carrier-wave provided externally to the A-IoT device         ETRI

R1-2403062         Discussion on Waveform characteristics of carrier-wave provided externally to the Ambient IoT device             CEWiT

R1-2403093         Discussion on waveform characteristics of carrier-wave provided externally to the Ambient IoT device             Google

R1-2403094         Considerations for waveform characteristics of carrier-wave              Semtech Neuchatel SA

R1-2403122         Considerations on carrier-wave transmission for Ambient IoT  LG Electronics

R1-2403199         Waveform characteristics of carrier-wave provided externally to the Ambient IoT device     Qualcomm Incorporated

R1-2403249         Study on waveform characteristics of carrier-wave for Ambient IoT         NTT DOCOMO, INC.

R1-2403399         Discussion on Carrier wave related aspects for AIoT  IIT Kanpur, Indian Institute of Technology Madras

R1-2403480         FL summary#1 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

From Monday session

Agreement

For CW waveform for D2R backscattering, multiple unmodulated single-tone is studied compared to single-tone in R19 SI.

·       Two unmodulated single-tones as a starting point

o   FFS: Other number of tones

o   FFS: how large gap is needed between tones

Agreement

For CW waveform for D2R backscattering, contiguous multi-tone OFDM signal is not studied in R19 SI.

R1-2403559         FL summary#2 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

Presented in Wednesday session

R1-2403639         FL summary#3 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

From Thursday session

Agreement

Study at least the following characteristics of unmodulated single-tone and multiple unmodulated single-tone CW waveforms for backscattering:

• For D2R

o   Reception performance

o   Spectrum utilization of backscattered signal corresponding to the CW waveforms

• CW interference suppression at D2R receiver

o   Including complexity and CW cancellation capability value/range (if any)

o   For scenarios ’A1’, ’A2’ and ’B’

• Relative complexity of CW generation

R1-2403766         FL summary#4 on CW waveform characteristics for A-IoT              Moderator (Spreadtrum Communications)

Presented in Friday session.

Final summary in R1-2403767.

 RAN1#117

9.4      Study on solutions for Ambient IoT (Internet of Things) in NR

Please refer to RP-240826 for detailed scope of the SI. For additional clarification on the work scope, please refer to section 8 of RP-240854.

R1-2405696         Session notes for 9.4 (Study on solutions for Ambient IoT in NR)       Ad-Hoc Chair (Huawei)

Friday decision: The session notes are endorsed and contents reflected below.

[117-R19-A_IoT] – Xiaodong (CMCC)

Email discussion on Rel-19 Ambient IoT

-        To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc

From Friday session

[Post-117-AIoT-01] – Xiaodong (CMCC)

Email discussion on remaining Ambient IoT evaluation assumptions from May 29 until June 5 (weekend is a quiet period)

·       Approval of note 1 of the link budget table (highlighted in yellow) in section 9.4.1.1 of R1-2405696.

·       Approval of the link level simulation table (highlighted in yellow) in section 9.4.1.1 of R1-2405696.

[Post-117-AIoT-02] – Xiaodong (CMCC)

Email discussion on link budget analysis, link-level simulation for A-IoT from August 7th until 14th

·       Companies are encouraged to provide link budget analysis and link-level simulation results by August 7th

·       Xiaodong to collect results, provide potential consolidated tables, proposals for observations by August 14th

Decision: The discussions are to be carried over to RAN1#118.

9.4.1       Evaluation on Ambient IoT in NR

9.4.1.1       Evaluation assumptions and results

Including assumptions on coverage and coexistence evaluations, link budget calculations, and remaining design targets of TR 38.848

R1-2403840         Evaluation assumptions and results for Ambient IoT   Ericsson

R1-2403858         Discussion on evaluation assumptions and results for Ambient IoT devices          FUTUREWEI

R1-2403885         Evaluation assumption and preliminary results for Ambient IoT              Tejas Networks Limited

R1-2403886         Evaluation assumptions and results for Ambient IoT   Nokia

R1-2403952         Evaluation methodology and assumptions for Ambient IoT              Huawei, HiSilicon

R1-2404026              Discussion on evaluation assumptions and results for Ambient IoT              Spreadtrum Communications

R1-2405364         Considerations for evaluation assumptions and results              Samsung              (rev of R1-2404115)

R1-2404177         Evaluation methodologies assumptions and results for Ambient IoT         vivo

R1-2404284         On evaluation assumptions and link budget analysis for AIoT              Apple

R1-2404401         The evaluation methodology and preliminary results of Ambient IoT         CATT

R1-2404427         Discussion on evaluation assumptions and results for Ambient IoT         China Telecom

R1-2404456         Discussion on evaluation methodology and assumptions              CMCC

R1-2404500         Initial evaluation results for Ambient IoT      Sony

R1-2404554         Discussion on Ambient IoT evaluations        ZTE, Sanechips

R1-2404618         Evaluation methodology and assumptions for Ambient IoT              Xiaomi

R1-2404793         Discussion on ambient IoT evaluation framework       NEC

R1-2404868         Discussion on evaluation assumptions and results for A-IoT              OPPO

R1-2404888         Discussion on Ambient IoT evaluation          LG Electronics

R1-2404939         Discussion on the evaluation assumptions for Ambient IoT devices  Lenovo

R1-2404957         Evaluation assumptions for Ambient IoT       InterDigital, Inc.

R1-2405042         Study on evaluation assumptions for Ambient IoT      NTT DOCOMO, INC.

R1-2405076         Evaluation assumptions and results MediaTek Inc.

R1-2405155         Evaluation Assumptions and Results             Qualcomm Incorporated

R1-2405214         Evaluation assumptions for Ambient IoT       Comba

R1-2405296         Evaluation assumption and preliminary results for AIoT           IIT Kanpur, Indian Institute of Tech (M)

R1-2405435         FL summary #1 for Ambient IoT evaluation           Moderator (CMCC)

From Monday session

Agreement

In the link level simulation, coherent and non-coherent receiver can be evaluated for D2R receiver.

Agreement

For CW2D pathloss model applied to the D1T1-A1/A2/B and D2T2-A1/A2/B scenarios, using the same pathloss model defined in TR38.901 as used for R2D/D2R.

Agreement

Add Row [0D] in the link budget table as follows:

Agreement

Update the link budget table Row [0C] as follows:

Agreement

·       For R2D link in the coverage evaluation for device 2,

o   Budget-Alt2 is used if receiver architecture is IF/ZIF ED is used

Agreement

Update the link budget table Row [1G] as follows:

Agreement

For the link level simulation,

·       An RMS delay spread of 30 ns and [150] ns is considered for TDL-A channel model.

·       An RMS delay spread of 30 ns is considered for TDL-D channel model.

R1-2405436         FL summary #2 for Ambient IoT evaluation           Moderator (CMCC)

From Wednesday session

Agreement

For the link level simulation in coverage evaluation, {20 bits, 96 bits, 400 bits} are considered for message size.

·       Note: companies to report the M value and chip length used for each message size

Agreement

For coverage evaluation,

·       In the case of CW outside topology with ‘B’ scenarios or CW inside topology with ’A1’ scenarios

o   The digital baseband processing of CW interference handling is not modelled in link level simulation (LLS). It is included in the link budget analysis by reporting the CW cancellation capability value(s) ([2K] in link budget table).

o   Note1: ’A2’ scenarios have already been agreed.

o   Note2: The study of CW interference cancellation capability value(s) at D2R receiver to be discussed in 9.4.2.4 for all scenarios (and if necessary ask RAN4 about the feasibility)

o   Note3: which scenarios to be evaluated is subject to other discussion.

Agreement

• For R2D link in the coverage evaluation for device 2,
• Budget-Alt1 is used if receiver architecture is RF ED
• Budget-Alt2 is used if receiver architecture is IF/ZIF ED
• Note1: this does not preclude to have LLS for device 1 and 2 R2D link with RF-ED if needed.
• Note1b: For device 2 R2D link with RF-ED, Budget-Alt1 is mandatory, Budget-Alt2 is optional.
• Note2: this does not imply all M values are achievable with the sensitivity given by Budget-Alt1 for RF ED
• Note3: For device 2 with an RF ED-based receiver on the R2D link, if the receiver sensitivity derived from Budget-Alt2, assuming a noise figure of [X dB], exceeds the receiver sensitivity based on Budget-Alt1, then Budget-Alt2 is applied.

Agreement

Update the link budget table Row [3A] as follows:

Agreement

Update the ED bandwidth parameter in link level simulation table as follows:

R1-2405437         FL summary #3 for Ambient IoT evaluation           Moderator (CMCC)

From Friday session

Working assumption:

·       For the D2R LLS, the SINR/SNR is reported and it is defined as the ratio of signal power to noise and interference (if any) power in the receiver bandwidth.

o   FFS: receiver bandwidth

·       On/off keying backscatter loss is not taken into account in the LLS and is included in link budget table [1H].

Agreement

For R2D ZIF receiver, report the same metrics (i.e., CNR/CINR, signal transmission bandwidth, ED bandwidth) as agreed for RF-ED/IF receiver.

Agreement

The link budget table is updated as follows (the yellow parts are not agreed and will be discussed by email),

<Editor Notes: Note 1 will be updated once the table has stabilized >

Note1 (for email discussion): calculated values in the Table XXXX are derived according to the followings,

[1M]:

• For R2D,
• [1M] = [1E] + [1G] - [1N] - FFS: [1J]
• For D2R
• Device 1:
• [1M] = [1E] + [1G] - [1H] - [1J]
• Device 2a:
• [1M] = [1E] + [1G] + [1K] - [1H] - [1J]
• Device 2b:
• [1M] = [1E] + [1G] - [1J]

[2F]:

·       [2F] = [2D] + [2E] +lin2dB([2B])

[2G]

·       For the R2D LLS for ED, CINR/CNR is reported, where CINR/CNR is defined as the ratio of signal power spectral density in the transmission bandwidth to the noise and interference (if any) power spectral density in the device ED channel bandwidth.

[2J]

·       For R2D link in the coverage evaluation, for device 1

o   Budget-Alt1 is used (note: receiver architecture is RF ED)

·       For R2D link in the coverage evaluation for device 2,

o   Budget-Alt1 is used if receiver architecture is RF ED

o   Budget-Alt2 is used if receiver architecture is IF/ZIF ED

·       Note1a: this does not preclude to have LLS for device 1 and 2 R2D link with RF-ED if needed.

·       Note1b: For device 2 R2D link with RF-ED, Budget-Alt1 is mandatory, Budget-Alt2 is optional.

·       Note1c: this does not imply all M values are achievable with the sensitivity given by Budget-Alt1 for RF ED

·       Note1d: For device 2 with an RF ED-based receiver on the R2D link, if the receiver sensitivity derived from Budget-Alt2, assuming a noise figure of [X dB], exceeds the receiver sensitivity based on Budget-Alt1, then Budget-Alt2 is applied.

[2K1]:

·       FFS:

o   Alt1: [2K1] = [1E1] + [1E2] - [2K] or

o   Alt2: [2K1] = [1E1] + [1E2] + [2C] - [2K]

[2K2]:

·        

[2L]:

·       For R2D and Budget-Alt2,

o   [2L] = [2G] - lin2dB([2B] / [1F]) + [2F]

o   Note 1e: the term ‘lin2dB([2B] / [1F])’ is applied due to scaling from CNR/CINR to SNR/SINR.

·       For D2R,

o   [2L] = [2G] + [2F] + [2K2], device 1/2a

o   [2L] = [2G] + [2F], device 2b

[4A]

·       [4A]=[1M]+[2C]-[2L]-[3A]-[3B]+[3C]+[3D]

·       Note 1f: For scenarios ‘A1’ and ‘A2’, The Device Tx Power is calculated by assuming CW2D pathloss = D2R pathloss. i.e.,

o   TBC: [4A] = 0.5*([1E1]+[1E2]-2*[3A]-2*[3B]-[1J]-[2L]+[2C]-[1H]) for device 1,

o   TBC: [4A] = 0.5*([1E1]+[1E2]-2*[3A]-2*[3B]-[1J]-[2L]+[2C]+[1K]) for device 2

Note2: (M) denotes the value is mandatory to be evaluated. (O) denotes the value can be optionally evaluated.

Proposal (for email discussion)

The link level simulation table is updated as follows,